【Day 29】打包工具 Turbopack 與 Webpack

2025 iThome 鐵人賽

DAY 29

Modern Web

從 React 學 Next.js：不只要會用，還要真的懂系列第 29 篇

17th鐵人賽 next.js turbopack

文科少女

2025-10-06 08:46:49

112 瀏覽

分享至

前面我們看了很多關於 Next.js 的用法，最後我們也來認識一下 Next.js 提供的打包工具 Turbopack。

什麼是打包工具？

打包工具是能夠將整個專案進行解析、轉譯等，將專案組成一組可以用在瀏覽器上的檔案的工具。在進行專案的打包時，打包工具會協助我們從入口檔案開始解析所有 dependency，並且將相關的檔案進行轉譯，例如將 TypeScript 轉譯成 JavaScript、將 JSX 轉譯成 JavaScript 等。除此之外，還會將專案進行 tree shaking，以及壓縮檔案等最佳化的動作，還有將整個程式碼進行 chunk 的切分。

簡單來說，打包工具的主要用途就是將專案原始碼變成可以在目標環境(瀏覽器或伺服器)高效運行的檔案組。

Turbopack 是什麼？

Turnopack 是 Vercel(Next.js 的團隊) 和 Webpack 作者以 Rust 這個語言為基底開發打包工具，在官方介紹文中更是直接號稱 Turbopack 是「the Rust-based successor to Webpack(基於 Rust 所實作的 Webpack 繼任者)」。這套打包工具強調的是能以更高的速度啟動及更新專案，所以主要優勢有超快啟動與熱更新(HMR)，並且靠著「增量建置(只重新 build 受影響的模組)」、「持久快取」、「多執行緒並行」與「按需解析/編譯」來大幅縮短開發迭代時間。Turbopack 主要用於 Next.js 這套框架的開發伺服器，並支援 RSC，也被應用於 Next.js 的 production 環境建置。除此之外，Turbopack 也很適合使用於大型專案及 monorepo 專案。

什麼是 Webpack？

Webpack 是大家最熟悉的打包工具之一，也是前端領域歷史上最悠久、影響力最大的打包工具。幾乎所有接觸過前端開發的人，都曾經使用過 Webpack。它的出現解決了以前瀏覽器缺乏模組化支援的問題，讓開發者可以把不同格式的資源，例如 JavaScript、CSS、圖片或字型，都透過 loader 與 plugin 整合到同一個專案中。也因為 Webpack 這套打包工具出現的時間比較早，讓 Webpack 累積了非常完整的生態系，不管遇到什麼情境，幾乎都能在相關社群或網站上找到對應的解決方案。

不過隨著專案規模不斷擴大，Webpack 的一些缺點也逐漸出現。由於 Webpack 的設定比較複雜，所以當想要調整時，往往需要耗費不少時間。在開發體驗上，Webpack 的冷啟動與熱更新速度在大型專案中也比較慢，這個狀況也就容易讓開發流程中斷。也因為這兩個狀況，在開發社群上開始有人在找更好的替代方案，這使得一些強調速度變快這個優勢的打包工具陸續出現，例如：Vite、Turbopack。

雖然前面有提到 Webpack 的設定比較複雜，但如果我們是使用 Next.js 這套框架下去進行開發，因為有很多基本的 loader 設定(例如：TailwindCSS、alias)都已經被 Next.js CLI 處理好了，所以即使是使用 Webpack 也不需要手動加上額外的設定。不過這是因為 Next.js 幫我們封裝好了 Webpack 配置，如果是非 Next.js 的 Webpack 專案，還是需要手動加 loader/plugin。

為什麼有 Webpack，還需要 Turbopack？

既然 Webpack 支援度很高也很穩定的打包工具，為什麼 Vercel 還要和 Webpack 作者一起推出另一套打包工具 Turbopack 呢？
主要原因可以歸納為以下幾點：

∙ 效能瓶頸：隨著專案規模增大，Webpack 在冷啟動時需要解析與處理大量模組，導致啟動速度明顯變慢。
∙ 開發體驗：在開發過程中，每當程式碼更新時，Webpack 的熱更新(HMR)會需要重新處理過多模組，導致無法快速反應更新後的內容，進而影響開發節奏。
∙ 框架整合：Webpack 雖然是通用型打包工具，但要支援 Next.js 必須仰賴 plugin，而實際整合度有限，設定也相對複雜。

這些限制與 Webpack 的底層架構有關。Webpack 使用 JavaScript 實作，雖然帶來了良好的可擴充性，但 JavaScript 本身是單執行緒的程式語言，比較難充分利用多核心效能。因此在大型專案中，無論是冷啟動還是 HMR，速度都容易被拖慢，再加上繁瑣的設定，對新手或團隊來說學習與維護成本都偏高。

在這樣的背景下，Vercel 與 Webpack 作者希望打造一個「繼承 Webpack 經驗，卻能徹底解決速度與體驗瓶頸」的新世代工具。由 Rust 開發的 Turbopack 因而誕生，目標就是提供更快的效能、更流暢的開發體驗，以及與 Next.js 更緊密的整合。

Turbopack 真的有比較快？Turbopack 與 Webpack 的速度比較

這裡也用實際的兩個專案來比較所謂的快慢部分。這兩個專案的都是 Next.js 專案，而且都是使用 App Router，但是一個是使用 Turbopack，一個是使用 Webpack。

專案的檔案架構如下：

my-project/
└── 📁 src/
    ├── 📁 components/
    │   ├── ClientCounter.tsx
    │   ├── ChartClient.tsx
    │   └── FancyButton.tsx     
    │
    ├── 📁 lib/               
    │   ├── i18n.ts          
    │   └── price.ts          
    │
    └── 📁 app/                        
        ├── layout.tsx                
        ├── page.tsx                  
        │
        ├── 📁 products/             
        │   ├── page.tsx               
        │   └── 📁 [id]/               
        │       └── page.tsx           
        │
        └── 📁 hmr-test/         # 專用 HMR 測試頁
            └── page.tsx

開發環境啟動速度

首先，我們先來看冷啟動的部分，所謂的冷啟動，也就是當我們一開始要把專案跑起來的動作。當我們執行 run dev 啟動專案後，會出現 Starting... Ready in XXXXms，我們會觀察這裡的秒數。

用使用 Webpack 的轉案和使用 Turbo 的專案各自跑 run dev 三次，可以看到的結果如下：
∙ 使用 Webpack 的專案的三次冷啟動時間：
1626ms
1740ms
1682ms
平均約 1682ms
∙ 使用 Turbopack 的專案的三次冷啟動時間：
1259ms
1362ms
1091ms
平均約 1250ms

熱更新(HMR)更新速度

再來我們嘗試改動其中一個頁面的內容，來看看熱更新的速度。這裡兩個專案都會修改同一個檔案 app/hmr-test/page.tsx，並且會修改三次來看花費多少時間完成更新。當我們位於這個頁面，進行修改後，會出現 Compiled /hmr-test in XXXms，我們會來觀察這裡的秒數。

實際測試的結果如下：
∙ 使用 Webpack 的專案的三次熱更新時間：
405ms
393ms
197ms
平均約 331ms
∙ 使用 Turbopack 的專案的三次熱更新時間：
36ms
112ms
42ms
平均約 60ms

Production Build

最後我們也來看進行 build 時的花費時間。當我們 run build 後，會出現 Compiled successfully in XXs 這段文字，我們會來觀察這裡顯示的秒數。

實際測試的結果如下：
∙ 使用 Webpack 的專案的三次 build 的時間：
5.7s
5.5s
5.9s
平均 5.7ms
∙ 使用 Turbopack 的專案的三次 build 的時間：
3.4s
2.7s
2.3s
平均 2.7ms

雖然這樣比較的方式不一定那麼的準確，但以我實測時的體感，還有以上述實際數據來看的話，的確還是可以感受到使用 Turbopack 的各個層面的速度都比 Webpack 的速度還要快。這裡只是建立一個小專案來做測試，當專案變大，體感上的速度差異也會更明顯。

Turbopack 的現況

現在想要在自己正式的專案使用 Turbopack，透過執行 npx create-next-app@latest 在設定選項中，選擇要使用 Turbopack，就能在初始化專案時，就選擇用 Turbopack 做開發，不需要額外於 next config 檔中開啟 Turbopack。

雖然目前於 Next.js 15 版本中，Turbopack 在開發模式下，也就是 next dev --turbopack 的使用情境中是穩定的狀態，但在正式版本的建置部分，也就是 next build --turbopack 的部分仍然還在 beta 的階段，所以如果想要部署 Turbopack build 出來的版本到正式環境上，可能就需要多考慮一下，因為多少可能還是有一些不太穩定的部分。不過 Next.js 官方在公告中也有提到，目前他們官方的許多Vercel 產品已經在使用 Turbopack build 的版本，並透過這樣實際的使用發現到一些需要優化的部分並持續改善和修正，所以 build 的部分變為穩定版本也是指日可待的。

總結

Turbopack 與 Webpack 一樣是一個打包工具，Turbopack 繼承了 Webpack 的經驗，並將基底改成 Rust，以帶來效能上的突破。雖然目前在 Turbopack 在 build 階段還處於 beta，但在 Next.js 的 dev 階段已經是穩定的狀態，且已經能明顯感受到速度與流暢度的提升。對於新專案來說，Turbopack 在改善開發體驗上已經值得嘗試，而對於既有專案或正式部署的部分，則可以依需求與風險承受度逐步導入。